In computer networks, application programs communicate with other application programs through network communications protocol stacks, such as TCP/IP protocol stacks. Network communications protocol stacks are usually implemented in software that is part of computer operating systems. Network applications access network communications protocol stacks via function calls provided by application programming interfaces (APIs) to the computer operating systems. One common application programming interface for accessing network communications protocol stacks is referred to as the sockets application programming interface. The sockets application programming interface was originally developed by the University of California at Berkeley as an interface to the TCP/IP protocol stack of the Berkeley UNIX operating system. AT&T developed a similar interface, based on a streams implementation referred to as Transport Layer Interface or (TLI), for the System V UNIX operating system. The Berkeley sockets interface has been adapted for use with the WINDOWS™ operating system. The WINDOWS™ version is often referred to as WINDOWS™ Sockets or Winsock.
The term “socket,” as used herein, refers to a data structure identified by a descriptor that an application uses to communicate with a remote application via a local communications protocol stack and is not intended to be limited to any operating-system-specific data structure. A socket may be created using a socket creation function call provided by a sockets API or a streams function call provided by a streams API. The function call returns a socket descriptor to the calling application that the application uses to send and receive data over a network in a manner similar to the way that an application reads and writes data to a file using a file descriptor. The term “sockets layer,” as used herein, is not intended to be limited to any operating-system-specific transport interface and instead is intended to refer generically to an application programming interface for accessing a network communications protocol stack, such as the sockets API or the streams transport layer interface (TLI).
Communications protocol stacks, sockets layers, and applications are typically implemented in different software layers. FIG. 1 illustrates a network application, a sockets layer, and a software-implemented network communications protocol stack. Referring to FIG. 1, network application 100 may be a client or a server that desires to communicate with other applications over a computer network. A sockets layer 102 provides sockets-related function calls that allow network application 100 to access a network communications protocol stack 104. In the illustrated example, network communications protocol stack 104 is a TCP/IP protocol stack. TCP/IP protocol stack 104 implements reliable, connection-oriented communications over an unreliable network. Exemplary functions performed by TCP/IP protocol stack include connection establishment and tear-down, message sequencing, timeout and retransmission, congestion control, and network layer routing. TCP/IP protocol stack 104 accesses underlying network 110 via network interfaces 106 and 108. Network interfaces 106 and 108 may be any suitable physical layer interfaces, such as Ethernet interfaces, for sending and receiving data over underlying network or networks 110. For example, network interfaces 106 and 108 may be connected to different IP subnets.
One problem with the architecture illustrated in FIG. 1 is that network communications protocol stack 104 consumes a large amount of processor cycles. For example, a TCP/IP protocol stack 104 implements connection establishment and tear-down, timeouts, retransmission, and other functions for each connection implemented through TCP/IP protocol stack 104. If network application 100 is a server, network application 100 may have multiple simultaneous connections through TCP/IP protocol stack 104. Concurrency can also exist in network clients, again resulting in multiple simultaneous connections through protocol stack 104. As a result, the processing required to implement TCP/IP protocol stack 104 is multiplied by the number of simultaneous connections. The processor that executes the instructions that implement TCP/IP protocol stack 104 becomes overloaded and the time for network application 100 to service each connection is increased.
In order to avoid the processor overload conditions that can be caused by software-implemented network communications protocol stacks, portions of network communications protocol stacks have been implemented in hardware. For example, hardware-implemented network communications protocol stacks, referred to as TCP offload engines or TOEs, move the data path of the network communications protocol stack to hardware, while the control portion of the network communications protocol stack is implemented in software. Moving the data path of the network communications protocol stack into hardware frees processor cycles to perform other functions, such as accepting more connections or performing application functions.
FIG. 2 is an example of a network communications protocol stack in which portions of the processing required for implementing the network communications protocol stack have been moved to hardware. Referring to FIG. 2, network communications protocol stack 200 includes TCP offload engines 202 and 204 that implement the data path portion of the TCP/IP protocol stack and a TCP/IP control layer 206 that implements the control portion of the TCP/IP protocol stack. TCP offload engines 202 and 204 may be implemented in hardware and may include integrated network interfaces for communicating over network 110. The data path portion of the TCP/IP protocol stack that may be implemented by TCP offload engines 202 and 204 may include sending and receiving data over network 110. The control portion of the TCP/IP protocol stack implemented by TCP/IP control layer 206 may include connection setup, connection tear down, and exceptions handling. TCP control layer 206 may be implemented in software. TCP/IP offload engines 202 and 204 share state information with TCP control layer 206. By off-loading portions of the TCP/IP protocol stack to hardware, the architecture illustrated in FIG. 2 increases the communication efficiency between application 100 and other applications.
Even though the architecture illustrated in FIG. 2 includes multiple TCP offload engines, the architecture functions as a single TCP/IP protocol stack, and a socket is associated with protocol stack when the socket is created. For example, when application 100 makes a socket creation function call via sockets layer 102, a socket is created and associated with protocol stack 206. This association is fixed for the life of the socket and cannot be altered using existing sockets APIs. While such an architecture may be useful in certain situations, future architectures may include multiple TCP/IP protocol stacks. However, because sockets layer 102 fixes the association between a socket and a communications protocol stack at socket creation time, an application can only communicate with remote applications over one protocol stack. If data arrives over a different protocol stack from the protocol stack with which the application's socket is associated, the data will not reach the application. Alternatively, the application must create a socket for each protocol stack, requiring the application to be aware of each protocol stack in the system. Requiring the application to be aware of each protocol stack in the system greatly increases the complexity of application design.
Accordingly, there exists a long felt need for methods, systems, and computer program products for controlling communications between network applications and a plurality of network communications protocol stacks.